fix: issue-5850 - Settle override conflicts between edges and propagate changes #7025

AlonNavon · 2023-11-26T13:37:13Z

A first step in fixing the overrides feature. In this PR I'm aiming to fix 3 bugs:

When we add an edge going into a node we update the node's overrides, but we don't update the overrides of that node's outgoing edges, and so forth. We need the up-to-date overrides to filter through.
When we remove an edge going into a node we don't update the overrides at all (and we don't update the outgoing edges like in the previous bug).
When we add an edge going in, and we already have a different override set for the node, we just ignore the existing override set and overwrite it with that of the new edge. Instead, this PR chooses the most specific override set. This still isn't the absolutely correct logic, since different override sets can have implications down the line of the dependency chain, but it has the advantage of being consistent (instead of just going with the last edge in). Also, it raises an error if it encounters a real conflict, meaning two incoming edges with override sets that aren't just a subset of one another.
So if we have dependency chains A->B->C and A->C, and we override C under B, then C will be overridden.

References

Fixes some of the override issues.

…e edges out

wraithgar · 2023-11-28T15:37:14Z

This is going to need tests

workspaces/arborist/lib/node.js

wraithgar · 2023-11-28T15:50:09Z

The edge's reload seems to me where this kind of thing should be happening. Is this a more subtle error perhaps where we're not reloading the overrides where we should?

AlonNavon · 2023-11-28T16:27:34Z

The edge's reload seems to me where this kind of thing should be happening. Is this a more subtle error perhaps where we're not reloading the overrides where we should?

There are several bugs in the mechanism, and this is just the first fix.
Here I handle the case where a node has two incoming edges with different override sets, and I percolate it downwards in the dependency tree. So I'm not sure why it should be in the edge's reload.
If you @wraithgar have time I can hop on a Google meet to discuss (and explain the other bugs).

AlonNavon · 2023-12-07T17:59:43Z

@wraithgar
The linter and the tests are successful (except a random failure in macOS 18.0 which is unrelated to the PR).

AlonNavon · 2023-12-18T12:08:47Z

@wraithgar Anything else we need to do to merge this?

sgarfinkel · 2023-12-26T17:18:24Z

@AlonNavon This looks awesome, really looking forward to having overrides work more the way you'd expect. With this change, will running npm install re-apply any npm overrides as expected, or will running npm u still be required? Hopefully this gets approved soon 👍

AlonNavon · 2023-12-26T17:45:22Z

@sgarfinkel
Hey, this is just the first fix. Concretely, there are at least 5 identifiable bugs. It fixes (1) and (2) and gives a reasonable solution for (3). I have other short PRs planned for (4) and (5), but first I want to merge this one. With those merged the behavior should be stable and correct (up to some freaky edge cases regarding the conflict resolution).
But I haven't been able to get this one merged yet. Hopefully after the holidays it will get renewed attention. Every upvote counts.

The major bugs:

No percolation to the out-edges.
Not updating when deleting in-edges.
No conflict resolution of override sets (though ultimately, edges with conflicting overrides shouldn't be valid and be deduplicated IMHO).
A certain flow that updates to the parent's overrides which doesn't make sense.
Mishandling version ranges on edges.

wraithgar · 2024-01-02T15:27:37Z

Anything else we need to do to merge this?

Just patience. Holidays are over and we got a lot of PRs. This PR is on the work board it's not been forgotten.

sgarfinkel · 2024-03-14T16:39:00Z

Why was this closed?

ljharb · 2024-03-14T16:41:13Z

The PR wasn't made from the OP's fork, but presumably from their company's (which means that maintainers can't push to the PR branch, btw - always only make PRs from your own personal forks), and presumably someone at their company deleted the fork.

AlonNavon · 2024-03-14T16:54:48Z

Yeah, this was a mistake on our end. Our devops deleted the repo by accident.
We restored the repo, but we need some maintainer with permissions to reopen the PR.
@sgarfinkel @ljharb @wraithgar

workspaces/arborist/lib/edge.js

workspaces/arborist/lib/node.js

workspaces/arborist/lib/edge.js

workspaces/arborist/lib/node.js

workspaces/arborist/lib/edge.js

AlonNavon · 2024-11-10T15:24:00Z

workspaces/arborist/lib/override-set.js

@@ -142,6 +181,24 @@ class OverrideSet {

    return ruleset
  }
+
+  static findSpecificOverrideSet (first, second) {


@jdalton I moved the functions here, because fundamentally they are about comparing override sets, so this is the most natural location for them I think.

Is there anything else, or do you approve the PR?

@AlonNavon
I think it looks great. Could you add code comments inline explaining the cases when the .silly is called (the one you changed from throwing to .silly). This will help folks if they see the logging know why.

Then the only other thing is adding any unit tests to cover some of the things you discovered and tweaked.

Hey @wraithgar, can you run the tests? To make sure nothing got accidentally broken with all the changes.

@jdalton For the override set functions I created unit tests. I'm not sure how to translate the test cases that I'm running to unit tests.
This is the package.json of the simplest case:
{ "name": "test", "version": "1.0.0", "engines": { "npm": ">=8.3.0" }, "dependencies": { "json-server": "0.17.0" }, "overrides": { "json-server": { "package-json": "7.0.0" } } }

Looks good to me. @wraithgar I think this is where we'll need your help to push it over the line. (one last test case and a review). 🎉

@AlonNavon

Heads up! Socket folks just noticed an issue with the lock files being generated and npm ci.

In Socket's case the new patched version of npm DOES produce a technically correct lock file, however the npm ci command is expecting an incorrect lock file and errors when the correct lock file does NOT conform.

The issue is around dealing with bundled dependencies. For example, the package @socketregistry/deep-equal has bundled dependencies which with this patch get correctly resolved and represented in the lock file. However, npm ci expects the lock file to be layedout in a way which ignores the bundled dep and looks for the dep hoisted in the higher node_modules folder even though it DOES NOT exist on disk.

All of this to say, I think there is something in npm ci that needs checking in on (I believe it does do a form of npm install). The workaround for Socket was to do the "fixed" install and then run npm install --ignore-scripts --package-lock-only to put back the incorrect, but expected by npm ci, lock entries. The --ignore-scripts --package-lock-only worked on the patched npm too. So something to investigate.

@AlonNavon Any insight into the issue above?

@jdalton @AlonNavon I just tried to reproduce this package-lock.json issue and wasn't able to. Using the patched and unpatched version gave me the same package-lock. I did notice that the socketregistry/deep-equal has a number of scripts, including update-package-lock.js which modifies the package-lock.json directly and forces another npm install.

workspaces/arborist/lib/override-set.js

workspaces/arborist/test/override-set.js

wraithgar · 2024-12-16T16:56:51Z

👋 We are shipping npm 11 this morning and will be able to focus on this issue again. This is a priority task for us this next quarter.

wraithgar · 2024-12-16T16:57:46Z

Had to close/reopen to get the "approve" button to show up again.

AlonNavon · 2024-12-19T10:19:08Z

👋 We are shipping npm 11 this morning and will be able to focus on this issue again. This is a priority task for us this next quarter.

That's great news! I really hope we can get this fix deployed soon 👍

owlstronaut · 2025-02-03T21:44:53Z

workspaces/arborist/lib/edge.js

@@ -103,7 +104,7 @@ class Edge {
  }

  satisfiedBy (node) {
-    if (node.name !== this.#name) {
+    if (node.name !== this.#name || !this.#from) {


Curious about this check. The constructor will throw a TypeError if from is falsey - do we need this and added checks to this.from?

@owlstronaut

Currently the ArboristEdge constructor does NOT throw and only assigns a this.from if edgeFrom != null (null or undefined). The Edge constructor uses ArboristEdge and DOES throw in its constructor if if (!from) {.

If the !this.#from isn't needed then the if (edgeFrom != null) { of ArboristEdge isn't needed either.

owlstronaut · 2025-02-04T00:08:53Z

workspaces/arborist/test/override-set.js

+    t.equal(OverrideSet.findSpecificOverrideSet(overrides5, overrides5), overrides5, "find more specific override set when the sets are identical")
+    t.equal(OverrideSet.findSpecificOverrideSet(overrides5, overrides6), overrides6, "find more specific override set when it's the second")
+    t.equal(OverrideSet.findSpecificOverrideSet(overrides6, overrides5), overrides6, "find more specific override set when it's the first")
+    t.ok(!OverrideSet.doOverrideSetsConflict(overrides1, overrides2), "override sets are equal")
+    t.ok(!OverrideSet.doOverrideSetsConflict(overrides5, overrides5), "override sets are the same object")
+    t.ok(!OverrideSet.doOverrideSetsConflict(overrides5, overrides6), "one override set is the specific version of the other")
+    t.ok(!OverrideSet.doOverrideSetsConflict(overrides6, overrides5), "one override set is the specific version of the other")
+    t.ok(OverrideSet.doOverrideSetsConflict(overrides5, overrides7), "no override set is the specific version of the other")
+    t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides5), "no override set is the specific version of the other")
+    t.ok(!overrides7.isEqual(overrides8), 'two override sets that differ in the version are not equal')
+    t.ok(!overrides8.isEqual(overrides9), 'two override sets that differ in the range are not equal')
+    t.ok(!overrides7.isEqual(overrides9), 'two override sets that differ in both version and range are not equal')
+    t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides8), "override sets are incomparable due to version")
+    t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides9), "override sets are incomparable due to version and range")
+    t.ok(OverrideSet.doOverrideSetsConflict(overrides8, overrides9), "override sets are incomparable due to range")
+


Suggested change

t.equal(OverrideSet.findSpecificOverrideSet(overrides5, overrides5), overrides5, "find more specific override set when the sets are identical")

t.equal(OverrideSet.findSpecificOverrideSet(overrides5, overrides6), overrides6, "find more specific override set when it's the second")

t.equal(OverrideSet.findSpecificOverrideSet(overrides6, overrides5), overrides6, "find more specific override set when it's the first")

t.ok(!OverrideSet.doOverrideSetsConflict(overrides1, overrides2), "override sets are equal")

t.ok(!OverrideSet.doOverrideSetsConflict(overrides5, overrides5), "override sets are the same object")

t.ok(!OverrideSet.doOverrideSetsConflict(overrides5, overrides6), "one override set is the specific version of the other")

t.ok(!OverrideSet.doOverrideSetsConflict(overrides6, overrides5), "one override set is the specific version of the other")

t.ok(OverrideSet.doOverrideSetsConflict(overrides5, overrides7), "no override set is the specific version of the other")

t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides5), "no override set is the specific version of the other")

t.ok(!overrides7.isEqual(overrides8), 'two override sets that differ in the version are not equal')

t.ok(!overrides8.isEqual(overrides9), 'two override sets that differ in the range are not equal')

t.ok(!overrides7.isEqual(overrides9), 'two override sets that differ in both version and range are not equal')

t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides8), "override sets are incomparable due to version")

t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides9), "override sets are incomparable due to version and range")

t.ok(OverrideSet.doOverrideSetsConflict(overrides8, overrides9), "override sets are incomparable due to range")

t.equal(OverrideSet.findSpecificOverrideSet(overrides5, overrides5), overrides5, 'find more specific override set when the sets are identical')

t.equal(OverrideSet.findSpecificOverrideSet(overrides5, overrides6), overrides6, "find more specific override set when it's the second")

t.equal(OverrideSet.findSpecificOverrideSet(overrides6, overrides5), overrides6, "find more specific override set when it's the first")

t.ok(!OverrideSet.doOverrideSetsConflict(overrides1, overrides2), 'override sets are equal')

t.ok(!OverrideSet.doOverrideSetsConflict(overrides5, overrides5), 'override sets are the same object')

t.ok(!OverrideSet.doOverrideSetsConflict(overrides5, overrides6), 'one override set is the specific version of the other')

t.ok(!OverrideSet.doOverrideSetsConflict(overrides6, overrides5), 'one override set is the specific version of the other')

t.ok(OverrideSet.doOverrideSetsConflict(overrides5, overrides7), 'no override set is the specific version of the other')

t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides5), 'no override set is the specific version of the other')

t.ok(!overrides7.isEqual(overrides8), 'two override sets that differ in the version are not equal')

t.ok(!overrides8.isEqual(overrides9), 'two override sets that differ in the range are not equal')

t.ok(!overrides7.isEqual(overrides9), 'two override sets that differ in both version and range are not equal')

t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides8), 'override sets are incomparable due to version')

t.ok(OverrideSet.doOverrideSetsConflict(overrides7, overrides9), 'override sets are incomparable due to version and range')

t.ok(OverrideSet.doOverrideSetsConflict(overrides8, overrides9), 'override sets are incomparable due to range')

owlstronaut · 2025-02-04T00:09:30Z

workspaces/arborist/lib/override-set.js

+    // The override sets are incomparable. Neither one contains the other.
+    log.silly('Conflicting override sets', first, second)
+  }
+


Suggested change

AlonNavon added 3 commits November 23, 2023 22:13

Settle overrides conflicts between edges, and propagate changes to th…

865070c

…e edges out

cleanup

cd20196

Optimization

0cad4e0

AlonNavon requested a review from a team as a code owner November 26, 2023 13:37

AlonNavon changed the title ~~Settle overrides conflicts between edges, and propagate changes to the edges out~~ fix: issue-5850 - Settle overrides conflicts between edges, and propagate changes to the edges out Nov 26, 2023

AlonNavon mentioned this pull request Nov 27, 2023

bug: overrides property only honored when running install the first time #5850

Open

wraithgar self-assigned this Nov 28, 2023

wraithgar reviewed Nov 28, 2023

View reviewed changes

workspaces/arborist/lib/node.js Outdated Show resolved Hide resolved

AlonNavon added 7 commits November 28, 2023 19:34

Fix override sets comparisons

6b276f3

Add comparator

fff3072

Check for undefined

e97176e

Another place

19155ed

Fix

dedbccf

Lint fixes

4a83786

Added tests

7ee2f2e

AlonNavon changed the title ~~fix: issue-5850 - Settle overrides conflicts between edges, and propagate changes to the edges out~~ fix: issue-5850 - Settle overrides conflicts between edges, and propagate changes Dec 7, 2023

AlonNavon changed the title ~~fix: issue-5850 - Settle overrides conflicts between edges, and propagate changes~~ fix: issue-5850 - Settle override conflicts between edges and propagate changes Dec 7, 2023

levpachmanov mentioned this pull request Feb 15, 2024

🚨 HIGH Severity Vulnerability: Package unsafe for use as of v1.1.8 🚨 indutny/node-ip#136

Open

ali-security closed this by deleting the head repository Mar 12, 2024

Static function

29f0750